IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
FIG. 1 illustrates schematically an overview of the 3GPP/TISPAN IMS architecture. Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS core network, and interface with other entities such as Border Gateway Control Functions (BGCFs) and Media Resource Function Controllers (MRFCs) amongst others. A Proxy CSCF (P-CSCF) is the first point of contact within the IMS for a SIP terminal; a Serving CSCF (S-CSCF) provides services to the subscriber; an Interrogating CSCF (I-CSCF) identifies the correct S-CSCF and forwards to that S-CSCF a request received from a SIP terminal via a P-CSCF.
Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Ma interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
The IMS architecture was originally designed to enable Public Land Mobile Network (PLMN) operators to offer their subscribers multimedia services based on and built upon Internet applications, services and protocols. As such, the architecture was optimized for supporting mobile users where each user was individually configured, represented and given resources in the network independently of each other. Support for fixed networks, such as public switched telephone network (PSTN), has therefore only subsequently been added to the IMS specification in an ad-hoc manner. In particular, IMS support for Private Branch Exchanges (PBX), which interconnect the internal telephones of a private organization and connects them to the PSTN via trunk lines, has only recently been given proper consideration by the ETSI TISPAN and the SIP FORUM organisations.
In this regard, a PBX can support IP/SIP (i.e. an IP-PBX) and can therefore register directly with the IMS. Alternatively, a PBX can be a legacy circuit switched PBX (i.e. CS PBX) that supports E1/T1/BRI links, and that connects to the IMS by way of at least one access gateway node that interworks between Time-Division Multiplexing (TDM) circuit switching used on the E1/T1/BRI links and SIP. Such an access gateway node can be an Integrated Access Device (IAD) located at the customer premises or a Multi Service Access Node (MASN) located at an operator site such as a telephone exchange. For example, TISPAN defines a Customer Network Gateway (CNG) that provides IAD functionality for a NGCN/PBX. FIG. 2 illustrates schematically a CS PBX having multiple connections/links to an IMS core network via multiple IADs/MSANs. Whilst not illustrated in FIG. 2, it is also possible that a single CS PBX be connected to a single IAD/MSAN by multiple TDM links, and that multiple CS PBXs can be connected to a single IAD/MSAN.
The IAD/MSAN essentially acts as a translator, converting the SIP signalling into signals that the CS PBX can interpret, and assigning a timeslot on the link (or one of the links) to the CS PBX to those signals according to local rules. The IAD/MSAN interprets the wildcarded portion of the IMPU in SIP requests directed to the PBX in order to ensure that the call is directed to the proper PBX using the proper CS link. If the IMPU is in the format of an E.164 number, this may simply involve inserting the E.164 into the signalling on the CS channel.
Each TDM link contains multiple channels, each of which occupies a certain timeslot in the TDM scheme. For PRI (E1/T1) and BRI TDM links, it may be desirable for operators to be able to configure each link such that the timeslots on the link are divided into those that are to be used for incoming calls (i.e. incoming timeslots), those that are to be used for outgoing calls (i.e. outgoing timeslots), and/or those that are can be used for either incoming calls or outgoing calls (i.e. bidirectional timeslots). Therefore, in circumstances in which a CS PBX connects to the IMS via at least one IAD or MSAN, both the CS PBX and the IAD/MSAN must have the same link timeslot configuration for each TDM link between the CS PBX and the IAD/MSAN.
Currently, timeslot configuration for the TDM links between an IAD/MSAN and a CS PBS (i.e. IAD/MSAN ports) requires manual Operation and Maintenance (O&M) configuration of each IAD/MSAN. However, such manual configuration of each IAD/MSAN is inefficient and increases the operating costs of an IAD/MSAN. Whilst it would be possible to provide each IAD/MSAN with an additional interface that allows each IAD/MSAN to be remotely provisioned with the link timeslot configuration this is not desirable as it places additional burdens on the IAD/MSAN manufacturers.